Methods And Systems For Application Program Interface Management

ABSTRACT

Provided are methods and systems for application program interface (API) management. An API management device may receive requests from client devices to submit an API and/or API update for implementation. The API management device may determine an operable status of the API and/or the API update by determining whether the API and/or the API update is configured and/or updated for implementation. The API and/or the API update may be determined to be configured and/or updated for implementation when the API and/or the API update does not violate one or more rules. The API management device, based on operable status, may allow or deny the request for implementation.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. Non-Provisional applicationSer. No. 16/441,455, filed on Jun. 14, 2019, which claims priority toU.S. Provisional Application No. 62/685,155, filed on Jun. 14, 2018,both of which are incorporated by reference in their entireties herein.

BACKGROUND

A user using an application programming interface (API) to build and/orupdate an application (e.g., source code, etc.) can experience problemssuch as improper, incomplete, and/or noncompliant implementations. Suchproblems can be the result of changes in version, state, stability,and/or the like associated with an API. Even though an API (e.g., sourcecode, etc.) may properly execute (e.g., compile and/or pass a testsuite), a user may be unable to determine changes in version, state,stability, and/or the like associated with an API, prior to committingthe application to a repository or deploying the application in a systemor network. As such, an application implemented according to the API mayperform improperly, fail, and/or be prone to security risk. These andother shortcomings are addressed by the methods and systems set forthherein.

SUMMARY

It is to be understood that both the following general description andthe following detailed description are exemplary and explanatory onlyand are not restrictive. Provided are methods and systems forapplication program interface (API) management. An API management device(e.g., a server, an interface device, a version control device/system, acomputing device, etc.) can receive a plurality of requests (e.g.,commands, instructions, etc.) from a plurality of client devices (e.g.,code generation devices, code management devices, API developmentdevices, etc.) to submit an API and/or an API update (e.g., source code,etc.) for implementation (e.g., a code build, a code commit, a codedistribution, etc.). The API management device can determine an operablestatus (e.g., operable index, operable value, etc.) of the API and/orthe API update by determining whether the API is configured and/orupdated for implementation. For example, a request (e.g., command,instruction, etc.) to implement an API and/or an API update can comprisea specification (e.g., API description, etc.) associated with the APIand/or the API update (or a portion of the API and/or the API update).The API management device, based on data (e.g., metadata, etc.)associated with the specification can verify the operable status of theAPI and/or the API update. Verifying the operable status of the APIand/or the API update can comprise one or more policy verifications toensure that the API and/or the API update adheres to one or more APIimplementation policies. The API management device, based on the one ormore policy verifications, can allow or deny the request forimplementation.

Additional advantages will be set forth in part in the description whichfollows or may be learned by practice. The advantages will be realizedand attained by means of the elements and combinations particularlypointed out in the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate embodiments and together with thedescription, serve to explain the principles of the methods and systems:

FIG. 1 is an example system in which the present methods and systems canoperate;

FIG. 2 is a flowchart of an example method;

FIG. 3 is a flowchart of an example method;

FIG. 4 is a flowchart of an example method; and

FIG. 5 is a block diagram of an example computing device.

DETAILED DESCRIPTION

Before the present methods and systems are disclosed and described, itis to be understood that the methods and systems are not limited tospecific methods, specific components, or to particular implementations.It is also to be understood that the terminology used herein is for thepurpose of describing particular embodiments only and is not intended tobe limiting.

As used in the specification and the appended claims, the singular forms“a,” “an,” and “the” include plural referents unless the context clearlydictates otherwise. Ranges may be expressed herein as from “about” oneparticular value, and/or to “about” another particular value. When sucha range is expressed, another embodiment includes from the oneparticular value and/or to the other particular value. Similarly, whenvalues are expressed as approximations, by use of the antecedent“about,” it will be understood that the particular value forms anotherembodiment. It will be further understood that the endpoints of each ofthe ranges are significant both in relation to the other endpoint, andindependently of the other endpoint.

“Optional” or “optionally” means that the subsequently described eventor circumstance may or may not occur, and that the description includesinstances where said event or circumstance occurs and instances where itdoes not.

Throughout the description and claims of this specification, the word“comprise” and variations of the word, such as “comprising” and“comprises,” means “including but not limited to,” and is not intendedto exclude, for example, other components, integers or steps.“Exemplary” means “an example of” and is not intended to convey anindication of a preferred or ideal embodiment. “Such as” is not used ina restrictive sense, but for explanatory purposes.

Disclosed are components that can be used to perform the disclosedmethods and systems. These and other components are disclosed herein,and it is understood that when combinations, subsets, interactions,groups, etc. of these components are disclosed that while specificreference of each various individual and collective combinations andpermutation of these may not be explicitly disclosed, each isspecifically contemplated and described herein, for all methods andsystems. This applies to all aspects of this application including, butnot limited to, steps in disclosed methods. Thus, if there are a varietyof additional steps that can be performed it is understood that each ofthese additional steps can be performed with any specific embodiment orcombination of embodiments of the disclosed methods.

The present methods and systems may be understood more readily byreference to the following detailed description of preferred embodimentsand the examples included therein and to the Figures and their previousand following description.

As will be appreciated by one skilled in the art, the methods andsystems may take the form of an entirely hardware embodiment, anentirely software embodiment, or an embodiment combining software andhardware aspects. Furthermore, the methods and systems may take the formof a computer program product on a computer-readable storage mediumhaving computer-readable program instructions (e.g., computer software)embodied in the storage medium. More particularly, the present methodsand systems may take the form of web-implemented computer software. Anysuitable computer-readable storage medium may be utilized including harddisks, CD-ROMs, optical storage devices, or magnetic storage devices.

Embodiments of the methods and systems are described below withreference to block diagrams and flowchart illustrations of methods,systems, apparatuses and computer program products. It will beunderstood that each block of the block diagrams and flowchartillustrations, and combinations of blocks in the block diagrams andflowchart illustrations, respectively, can be implemented by computerprogram instructions. These computer program instructions may be loadedonto a general purpose computer, special purpose computer, or otherprogrammable data processing apparatus to produce a machine, such thatthe instructions which execute on the computer or other programmabledata processing apparatus create a means for implementing the functionsspecified in the flowchart block or blocks.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including computer-readableinstructions for implementing the function specified in the flowchartblock or blocks. The computer program instructions may also be loadedonto a computer or other programmable data processing apparatus to causea series of operational steps to be performed on the computer or otherprogrammable apparatus to produce a computer-implemented process suchthat the instructions that execute on the computer or other programmableapparatus provide steps for implementing the functions specified in theflowchart block or blocks.

Accordingly, blocks of the block diagrams and flowchart illustrationssupport combinations of means for performing the specified functions,combinations of steps for performing the specified functions and programinstruction means for performing the specified functions. It will alsobe understood that each block of the block diagrams and flowchartillustrations, and combinations of blocks in the block diagrams andflowchart illustrations, can be implemented by special purposehardware-based computer systems that perform the specified functions orsteps, or combinations of special purpose hardware and computerinstructions.

Provided are methods and systems for application program interface (API)management. An API management device (e.g., a server, an interfacedevice, a version control device/system, a computing device, etc.) canreceive a plurality of requests (e.g., commands, instructions, etc.)from a plurality of client devices (e.g., code generation devices, codemanagement devices, API development devices, etc.) to submit an APIand/or an API update (e.g., source code, etc.) for implementation (e.g.,a code build, a code commit, a code distribution, etc.). The APImanagement device can determine an operable status (e.g., operableindex, operable value, etc.) of the API and/or the API update bydetermining whether the API and/or the API update is configured and/orupdated for implementation. The API and/or the API update can bedetermined to be configured and/or updated for implementation if the APIand/or the API update does not violate one or more rules (e.g., one ormore rules of an API governance policy, etc.). For example, a request(e.g., command, instruction, etc.) to implement an API and/or an APIupdate can comprise a specification (e.g., API description, etc.)associated with the API and/or the API update (or a portion of the APIand/or the API update). The API management device, based on data (e.g.,metadata, etc.) associated with the specification can determine theoperable status of the API and/or the API update.

Determining an operable status of an API and/or an API update cancomprise determining whether the API and/or the API update adheres toand/or violates one or more rules (e.g., policies, etc.). The one ormore rules can be associated with versioning, visibility, deprecation,and the like. For example, the API management device (e.g., a server, aninterface device, a version control device/system, a computing device,etc.) can determine a current version of an API, assign a version to theAPI, determine a version history associated with an API, and the like.The API management device can determine/verify a visibility attributeassociated with an API. For example, the API management device candetermine if an API and/or an API update (or a portion of the API and/orthe API update) is private, public, partnered, or the like). The APImanagement device can determine/verify a stability/developmentalrule/status associated with an API and/or an API update. For example,the API management device can determine if an API and/or an API update(or a portion of the API and/or the API update) is in an experimentalstate (e.g., operating below a performance threshold, etc.), a stablestate (e.g., operating according to a performance threshold, etc.), or alocked state, and/or the like. The API management device candetermine/verify a deprecation rule associated with an API and/or an APIupdate. For example, the API management device can determine portions ofan API and/or an API update that have been removed, modified, or thelike in accordance with and/or in violation of one or more settings(e.g., rules, attributes, policies, an API governance policy, etc.),such as a predefined time period.

The API management device, based on the operable status of an API and/oran API update, can allow or deny a request for implementation. Forexample, the API management device can determine the operable status ofan API and/or an API update and/or update the operable status of the APIand/or the API update prior to submitting (e.g., transmitting,providing, etc.) the API and/or the API update (e.g., source code, etc.)to one or more implementation devices (e.g., code repositories, codeexecutors, production servers, etc.).

The methods and systems described herein for API management may be usedto improve functioning of a code development environment by preventingAPIs and/or API updates (e.g., source codes, etc.) from beingimplemented with a misconfiguration(s) that may limit, prevent, or alterfunctionality of an API and/or an API update, even though the API and/orthe API update (e.g., source code, etc.) may compile and/or pass an APItest suite. For example, an API management device can be used to verifythat an API and/or an API update can operate as expected, such aswithout errors and/or according to a requirements specification.Additionally, an API management device can identify/prevent regressionsbetween API and/or API update releases. Thus, the methods and systemsdescribed herein for API management represent an improvement to existingAPI management methods and systems known in the art.

FIG. 1 illustrates various aspects of an exemplary environment in whichthe present methods and systems can operate. The present disclosure isrelevant to systems and methods for application program interface (API)management. Those skilled in the art will appreciate that presentmethods may be used in various types of networks and systems that employboth digital and analog equipment. One skilled in the art willappreciate that provided herein is a functional description and that therespective functions can be performed by software, hardware, or acombination of software and hardware.

The system 100 can comprise a client device 102 in communication with anapplication program interface (API) management device 104 (e.g., aserver, an interface device, a version control device/system, acomputing device, etc.). The API management device 104 can be disposedlocally or remotely relative to the client device 102. As an example,the client device 102 and the API management device 104 can be incommunication via a private and/or public network 105 such as theInternet or a local area network. Other forms of communications can beused such as a direct interface, as well as wired and wirelesstelecommunication channels, for example.

The client device 102 can be a device such as a code generation device,a code management device, an API development device, a computer, asmartphone, a laptop, a tablet, or other device capable of communicatingwith the API management device 104 (e.g., server, interface device,version control device/system, computing device, etc.). As an example,the client device 102 can comprise a communication element 106 forproviding an interface to a user (e.g., a developer) to interact withthe client device 102 and/or the API management device 104. Thecommunication element 106 can be any interface for presenting and/orreceiving information to/from the user, such as user feedback. Anexample interface may be communication interface such as a web browser(e.g., Internet Explorer®, Mozilla Firefox®, Google Chrome®, Safari®, orthe like). Other software, hardware, and/or interfaces can be used toprovide communication between the user and one or more of the clientdevice 102 and the API management device 104. As an example, thecommunication element 106 can request or query various files from alocal source and/or a remote source. As a further example, thecommunication element 106 can transmit data (e.g., source code, codecommit requests/commands, etc.) to a local or remote device such as theAPI management device 104.

The client device 102 can be associated with a client identifier ordevice identifier 108. As an example, the device identifier 108 can beany identifier, token, character, string, or the like, fordifferentiating one user (e.g., developer, etc.) or client device (e.g.,client device 102) from another user or client device. The deviceidentifier 108 can identify a user or client device as belonging to aparticular class of users or client devices. As a further example, thedevice identifier 108 can comprise information relating to the clientdevice 102 such as a manufacturer, a model or type of device, a serviceprovider associated with the client device 102, a state of the clientdevice 102, a locator, and/or a label or classifier. Other informationcan be represented by the device identifier 108.

The device identifier 108 can comprise an address element 110 and aservice element 112. The address element 110 can comprise or provide aninternet protocol address, a network address, a media access control(MAC) address, an Internet address, or the like. For example, theaddress element 110 can be relied upon to establish a communicationsession between the client device 102 and the API management device 104(e.g., server, interface device, version control device/system,computing device, etc.) or other devices and/or networks. As a furtherexample, the address element 110 can be used as an identifier or locatorof the client device 102. The address element 110 can be persistent fora particular network.

The service element 112 can comprise an identification of a serviceprovider associated with the client device 102 (e.g., code generationdevice, code management device, API development device, etc.) and/orwith the class of client device 102. The class of the client device 102can be related to a type of device, capability of device, type ofservice being provided, and/or a level of service (e.g., business class,service tier, service package, etc.). As an example, the service element112 can comprise information relating to or provided by a communicationservice provider (e.g., Internet service provider) that is providing orenabling data flow such as communication services to the client device102. As a further example, the service element 112 can compriseinformation relating to a preferred service provider for one or moreparticular services relating to the client device 102. In an aspect, theaddress element 110 can be used to identify or retrieve data from theservice element 112, or vice versa. As a further example, one or more ofthe address element 110 and the service element 112 can be storedremotely from the client device 102 and retrieved by one or more devicessuch as the client device 102 and the API management device 104. Otherinformation can be represented by the service element 112.

The client device 102 (e.g., code generation device, code managementdevice, API development device, etc.) can comprise a build and testmodule 113. A user (e.g., developer, etc.) can use the client device 102to generate/develop and application program interface (API) and/or anAPI update. The build and test module 113 can define semantics of an APIand/or an API update. The build and test module 113 can determine anarchitecture style of an API and/or an API update (e.g., an event-drivenAPI, a CRUD-based API, a hypermedia API, etc.). The build and testmodule 113 can define resources and resource states of an API and/or anAPI update. The build and test module 113 can determine a specificationfor an API and/or an API update to facilitate API and/or an API updateusage and implementation. For example, the build and test module 113 candetermine a specification for an API and/or an API update that definesroutines, data structures, object classes, variables, and the likeassociated with the API and/or the API update. The build and test module113 can provide an API and/or an API update to the API management device104 (e.g., server, interface device, version control device/system,computing device, etc.) for analysis. For example, the build and testmodule 113 can provide an API and/or an API update to the API managementdevice 104 for analysis via a request, such as HTTP POST or any otherrelated method.

The API management device 104 can be a device such as a server, aninterface device, a version control device/system, a computing device,and/or the like. The API management device 104 can communicate with theclient device 102 (e.g., code generation device, code management device,API development device, etc.) for providing data and/or services. As anexample, the API management device 104 can provide services such as APImanagement service (e.g., API versioning, API visibility analysis, APIdeprecation analysis, API break change analysis, etc.). The APImanagement device 104 can allow the client device 102 to interact withremote resources such as data, devices, and files. For example, the APImanagement device 104 can be configured as (or disposed at) a centrallocation (e.g., a headend, or processing facility), which can receivecontent (e.g., applications, source code, data, etc.) from multiplesources. The API management device 104 can combine the content from themultiple sources and can distribute the content to user (e.g.,developer, subscriber, etc.) locations via a distribution system.

The API management device 104 (e.g., server, interface device, versioncontrol device/system, computing device, etc.) can manage thecommunication between the client device 102 (e.g., code generationdevice, code management device, API development device, etc.) and adatabase 114 for sending and receiving data therebetween. For example,the database 114 can store a plurality of files (e.g., operablestatuses, stability indices, visibility attributes, deprecationpolicies, API source code, API statistical information, API policyinformation, code commit information, pull requests, etc.), clientidentifiers and/or records, or other information. As a further example,the client device 102 can request and/or retrieve a file from thedatabase 114. The database 114 can store information relating to theclient device 102 such as the address element 110 and/or the serviceelement 112. As an example, the API management device 104 can obtain thedevice identifier 108 from the client device 102 and retrieveinformation from the database 114 such as the address element 110 and/orthe service elements 112. As a further example, the API managementdevice 104 can obtain the address element 110 from the client device 102and can retrieve the service element 112 from the database 114, or viceversa. Any information can be stored in and retrieved from the database114. The database 114 can be disposed remotely from the API managementdevice 104 and accessed via direct or indirect connection. The database114 can be integrated with the computing system 104 or some other deviceor system.

The API management device 104 (e.g., server, interface device, versioncontrol device/system, computing device, etc.) can receive anapplication programming interface (API) from a client device (e.g., theclient device 102, a code generation device, a code management device,an API development device, etc.) or any other device. The API managementdevice 104 can receive an API from a client device e.g., the clientdevice 102, a code generation device, a code management device, an APIdevelopment device, etc.) or any other device via a communication module117. The communication module 117 can support a variety of communicationprotocols and communication techniques. For example, the communicationmodule 117 can support communication protocols, such as hypertexttransfer protocol (HTTP) (e.g., HTTP POST, HTTP REST, HTTP GET, HTTPPULL, HTTP PUSH, etc.), transmission control protocol (TCP), userdatagram protocol (UDP), and/or any other protocol. The communicationmodule 117 can support communication techniques such as long-rangecommunication techniques (e.g., Internet, cellular, satellite, etc.),and short-range communication techniques (e.g., BLUETOOTH®, near-fieldcommunication, infrared, etc.).

The API management device 104 (e.g., server, interface device, versioncontrol device/system, computing device, etc.) can transmit and/orprovide APIs received via the communication module 117 to animplementation device 116 (e.g., code repository, code executor,production server, etc.) for implementation. For example, thecommunication module 117 can comprise a representational state transfer(REST) interface for receiving API objects. The API management device104 can, prior to transmitting and/or providing an API and/or an APIupdate to the implementation device 116, can analyze API objects anddetermine an operable status (e.g., operable index, operable value,etc.) of the API and/or the API update. The API management device 104can determine an operable status of the API and/or the API update and,based on the operable status, either proceed with or terminatetransmitting and/or providing the API (or any API) to an implementationdevice 116 for implementation. Terminating, based on the operablestatus, a transmission of an API and/or an API update to animplementation device 116 can prevent the API and/or the API update (orany API/API update) from being implemented with misconfiguration thatcan limit, prevent, or alter functionality of the API and/or the APIupdate. A misconfiguration can limit, prevent, or alter functionality ofan API and/or an API update even though the API and/or the API updatemay compile and/or pass an API test suite (e.g., the build and testmodule 113).

The API management device 104 (e.g., server, interface device, versioncontrol device/system, computing device, etc.) can determine an operablestatus (e.g., operable index, operable value, etc.) of an API and/or anAPI update by determining whether the API and/or the API update isconfigured and/or updated for implementation. For example, a request(e.g., command, instruction, etc.) to implement an API and/or an APIupdate can comprise a specification (e.g., API description, etc.)associated with the API and/or the API update (or a portion of the APIand/or the API update). The API management device 104, based on data(e.g., metadata, etc.) associated with the specification can determinethe operable status of the API and/or the API update.

The API management device 104 (e.g., server, interface device, versioncontrol device/system, computing device, etc.) can comprise a compliancemodule 119. The compliance module 119 can determine whether the APIand/or the API update adheres to and/or violates one or more rules(e.g., policies, etc.). The one or more rules can be associated withversioning, visibility, deprecation, and the like. The compliance module119 can ensure that all APIs (or API updates) areverified/validated/approved for implementation (e.g., API implementationvia the implementation device 116, etc.) and adhere to the one or morerules (e.g., policies, etc.). The compliance module 119, based on theone or more rules can determine an operable status (e.g., operableindex, operable value, etc.) of an API and/or an API update.

The compliance module 119 can determine an operable status of an APIand/or an API update based on versioning associated with the API and/orthe API update. For example, the compliance module 119 can determine acurrent version of an API and/or an API update, assign a version to anAPI and/or an API update, determine a version history associated with anAPI and/or an API update, and the like. The compliance module 119 candetermine a current version of an API and/or an API update, assign aversion to an API and/or an API update, determine a version historyassociated with an API and/or an API update, and the like based on aspecification associated with the API and/or the API update (e.g., avalue within the specification, etc.). For example, the API managementdevice 104 can receive an API and/or an API update and an associated APIspecification from a client device (e.g., the client device 102, etc.).The API management device 104 can store the API specification (e.g., APIspecifications can be stored in a database 114, etc.). The compliancemodule 119 can use the API specifications as baseline information fordetermining changes (e.g., version changes, etc.) to an API based on APIupdate information received from a client device (e.g., the clientdevice 102, etc.). The compliance module 119 can determine changes(e.g., version changes, etc.) to an API to ensure that the API, whenimplemented, performs as a user (e.g., developer, etc.) may expect. Thecompliance module 119 can enable/disable changes to an API. For example,when the API management device 104 (e.g., the compliance module 119)receives an API update comprising a major version update of the API,then one or more portions of the API can be added, removed, or updated.

The compliance module 119 can determine an operable status of an APIand/or an API update based on a visibility attribute associated with theAPI. For example, the API management device, based on an APIspecification, can determine if the API and/or the API update (or aportion of the API and/or the API update) is private, public, partnered,restricted, or the like. The API management device 104 (e.g., thecompliance module 119) can ensure that one or more rules (e.g., apolicy, etc.) associated with the API and/or the API update are adheredto by the API and/or the API update. For example, the compliance module119 can be configured to prevent a visibility attribute associated withan API and/or an API update from transitioning from “Public” to“Private” without first being deprecated according to the one or morerules (e.g., the policy, an API governance policy, etc.). The compliancemodule 119 can be configured to automatically update API specification(e.g., API specification information stored in the database 114, etc.)according to a visibility attribute update, change, and/or modification.

The compliance module 119 can determine an operable status of an APIand/or an API update based on a stability index associated with the APIand/or the API update. For example, the compliance module 119 candetermine/verify a stability index (e.g., stability attribute,developmental rule, status, etc.) associated with an API and/or an APIupdate. A stability index can indicate whether an API and/or an APIupdate (or a portion of the API and/or the API update) is in anexperimental state (e.g., an API/API update under development, anAPI/API update operating below a performance threshold, an API/APIupdate the may be removed based on versioning, etc.), a stable state(e.g., a reliable API/API update, an API/API update not subject tochange or revision, an API/API update operating according to aperformance threshold, etc.), a locked state (e.g., a API/API updatethat is significantly reliable and/or not subject to a change orrevision, etc.) and/or the like. The compliance module 119, based on astability index, can ensure development and implementation of an APIand/or an API update can only move in one direction, such as from anexperimental state, to a stable state, to a locked state.

The compliance module 119 can determine an operable status of an APIand/or an API update based on a deprecation rule associated with the APIand/or the API update. The compliance module 119 can determine/verify adeprecation rule associated with an API and/or an API update based oninformation received with the API and/or an API update (e.g., an APIspecification, etc.). The compliance module 119, based on a deprecationrule, can determine portions of an API and/or an API update that haveremoved, modified, or the like in accordance to and/or in violation ofone or more settings (e.g., rules, attributes, deprecation policies,etc.), such as a determined time period. The determined time period canbe based on a visibility attribute, a stability index, or any otherfactor. For example, the compliance module 119 can determine whether aportion of an API has been removed, modified, or the like, such as by anAPI update, by determining a date of deprecation associated with theportion of the API. The compliance module 119 can determine adeprecation period for the portion of the API and determine whether atime period between a date of the API update and the date of deprecationexceeds the deprecation period.

The API management device 104, based on the operable status of an APIand/or an API update, can allow or deny a request from a client device(e.g., the client device 102) or any other device for implementation ofan API and/or an API update. For example, the API management device 104can determine the operable status of an API and/or update the operablestatus of the API prior to submitting (e.g., transmitting, providing,etc.) the API (e.g., source code, etc.) to an implementation device(e.g., the implementation device 116, a code repository, a codeexecutors, a production server, etc.). Determine the operable status ofan API and/or update the operable status of the API prior to submittingthe API to an implementation device improves functioning of a code(e.g., API, etc.) development environment by preventing APIs (e.g.,source codes, etc.) and/or API updates from being implemented withmisconfiguration that can limit, prevent, or alter functionality of anAPI.

In an aspect, the client device 102, the API management device 104, andthe implementation device 116 can be parts/components of a singledevice. In an aspect, the client device 102, the API management device104, and the implementation device 116 can be separate devices.

FIG. 2 is a flowchart of an example method 200 for API management. At210, a command/request to implement an API and/or an API update can bereceived. An application program interface (API) management device(e.g., the API management device 104, version control system, etc.) canreceive a command/request to implement an API and/or an API update. Thecommand/request can be from a client device (e.g., the client device102, a code generation device, a code management device, an APIdevelopment device, etc.). Implementing the API and/or the API updatecan comprise transmitting/providing the API and/or the API update to animplementation device (e.g., the implementation device 116, a coderepository, a code executor, a production server, etc.) to perform acode commit (e.g., a push request etc.), or any other operation. In anaspect, implementing an API and/or an API update can comprisetransmitting/providing the API and/or the API update to animplementation device and/or an API management device to perform a codepull (e.g., a pull request, etc.). In an aspect, implementing an APIand/or an API update can comprise transmitting/providing the API (e.g.,source code, executable, etc.) and/or the API update to animplementation device with the executable including a compiled versionof the API and/or the API update.

At 220, it can be determined if the API and/or the API update violatesone or more rules (e.g., one or more rules of an API governance policy,etc.), such as one or more rules that must be adhered to after an updateis implemented. The application program interface (API) managementdevice (e.g., the API management device 104, version control system,etc.) can determine whether the API and/or the API update violates oneor more rules (e.g., one or more rules of an API governance policy,etc.). The one or more rules (e.g., one or more rules of an APIgovernance policy, etc.) can be applicable to compilable and/ornon-compilable code. The one or more rules can be based on visibility,stability, deprecation, and/or the like.

The API management device (e.g., the API management device 104, versioncontrol system, etc.) can determine if the API and/or the API updateviolates one or more rules (e.g., one or more rules of an API governancepolicy, etc.) associated with versioning. For example, the APImanagement device can determine whether the API and/or the API updateviolates the one or more rules by determining whether a version numberassociated with the API and/or the API update is incremented accordingto the one or more rules. The API management device can determine acurrent version of the API and/or the API update, assign a version tothe API and/or the API update, determine a version history associatedwith the API and/or the API update, and the like based on an APIspecification associated with the API and/or the API update. The APImanagement device can receive the API specification from the clientdevice. The API management device can use the API specification asbaseline information to determine if changes (e.g., version changes,etc.) to the API and/or the API update violate the one or more rules(e.g., the one or more rules of an API governance policy, etc.).

The API management device (e.g., the API management device 104, versioncontrol system, etc.) can determine changes (e.g., version changes,etc.) to an API and/or an API update to ensure that the API and/or theAPI update, when implemented, performs as a user (e.g., developer, etc.)may expect. The API management device can enable/disable changes to anAPI and/or an API update. For example, when the API management devicereceives an API and/or an API update comprising a major version updateof the API, then one or more portions of the API and/or an API updatecan be added, removed, or updated.

The API management device (e.g., the API management device 104, versioncontrol system, etc.) can determine if the API and/or the API updateviolates one or more rules (e.g., one or more rules of an API governancepolicy, etc.) associated with a visibility attribute of the API and/orthe API update. For example, the API management device, based on the APIspecification, can determine whether the API and/or the API update (or aportion of the API and/or the API update) is private, public, partnered,restricted, or the like. For example, the API specification may indicatea particular visibility attribute to be associated with the API and/orthe API update (or a portion of the API and/or the API update). The APImanagement device can access code associated with the API and/or the APIupdate (or a portion of the API and/or the API update) to determine if avisibility attribute within the code coincides with a the visibilityattribute indicated by the API specification. The API management devicecan be configured to prevent a visibility attribute associated with anAPI (e.g., a non-deprecated portion of the API) from transitioning from“Public” (e.g., as indicated by the API specification) to “Private”without first being deprecated according to the one or more rules (e.g.,one or more rules of an API governance policy, etc.). The API managementdevice can be configured to automatically update an API specification(e.g., API specification information stored in the database 114, etc.)according to a visibility attribute update, change, and/or modification.

The API management device (e.g., the API management device 104, versioncontrol system, etc.) can determine if the API and/or the API updateviolate one or more rules (e.g., one or more rules of an API governancepolicy, etc.) associated with stability (e.g., a stability indexassociated with an API and/or an API update). For example, the APImanagement device can determine/verify a stability index (e.g.,stability attribute, developmental rule, status, etc.) associated withan API and/or an API update. A stability index can indicate whether theAPI and/or the API update (or a portion of the API and/or the APIupdate) is in an experimental state (e.g., an API under development, anAPI operating below a performance threshold, an API the may be removedbased on versioning, etc.), a stable state (e.g., a reliable API, an APInot subject to change or revision, an API operating according to aperformance threshold, etc.), a locked state (e.g., a API that issignificantly reliable and/or not subject to a change or revision, etc.)and/or the like. The API management device, based on a stability index,can determine if the API and/or the API update violate one or more rules(e.g., one or more rules of an API governance policy, etc.) associatedwith development and implementation of the API and/or the API update canonly move in one direction, such as from an experimental state, to astable state, to a locked state.

The API management device (e.g., the API management device 104, versioncontrol system, etc.) can determine if the API and/or the API updateviolate one or more rules (e.g., one or more rules of an API governancepolicy, etc.) associated with deprecation of the API and/or the APIupdate. The API management device can determine/verify a deprecationrule associated with an API based on information received with the API(e.g., an API specification, etc.). The API management device, based ona deprecation rule, can determine portions of an API that have removed,modified, or the like in accordance to and/or in violation of the one ormore rules (e.g., one or more rules of an API governance policy, etc.),such as a determined time period. The determined time period can bebased on the visibility attribute, the stability index, or any otherfactor. For example, the API management device can determine whether aportion of an API and/or the API update has been removed, modified, orthe like, such as by an API update, by determining a date of deprecationassociated with the portion of the API and/or the API update. The APImanagement device can determine a deprecation period for the API and/orthe API update and determine whether a time period between a date of theAPI and/or the API update and the date of deprecation exceeds thedeprecation period.

Based on whether API and/or the API update violate the one or more rules(e.g., the one or more rules of an API governance policy, etc.), the APImanagement device (e.g., the API management device 104, version controlsystem, etc.) can either deny or allow the command/request to implementthe API and/or the API update.

At 230, the command/request to implement the API and/or the API updatecan be denied. The command/request to implement the API and/or the APIupdate can be denied if the API and/or the API update violate the one ormore rules (e.g., the one or more rules of an API governance policy,etc.). The API management device (e.g., the API management device 104,version control system, etc.) can deny the command/request to implementthe API and/or the API update. Denying the command/request to implementthe API and/or the API update can comprise denying a command/request toperform a code commit (e.g., a push request etc.), or any otheroperation. Denying the command/request to implement the API and/or theAPI update can prevent APIs and/or the API updates from being committedto a implementation device (e.g., the implementation device 116, a coderepository, a code executor, a production server, etc.) that do notadhere to an expected API functionality and/or convention, even thoughthe APIs and/or the API updates (e.g., source code) may compile withouterror and/or pass through a test suite.

At 240, the command/request to implement the API and/or the API updatecan be allowed. The command/request to implement the API and/or the APIupdate can be allowed if the API and/or the API update do not violatethe one or more rules (e.g., the one or more rules of an API governancepolicy, etc.). The API management device (e.g., the API managementdevice 104, version control system, etc.) can allow the command/requestto implement the API and/or the API update. Allowing the command/requestto implement the API and/or the API update can comprise allowing acommand/request to perform a code commit (e.g., a push request etc.), orany other operation.

FIG. 3 is a flowchart of an example method 300 for application programinterface (API) management. At step 310, a command to perform a codecommit comprising an Application Program Interface (API) update may bereceived. As an example, an API management device (e.g., the APImanagement device 104, version control system, etc.) may receive thecommand from a client device (e.g., the client device 102, a codegeneration device, a code management device, an API development device,etc.). Implementing the command to perform the code commit (e.g.,implementing the API and/or performing an update to the API) maycomprise transmitting/providing the code commit to an implementationdevice (e.g., the implementation device 116, a code repository, a codeexecutor, a production server, etc.). The implementation device maycarry out performance of the code commit (e.g., a push request etc.), orany other operation related to the command. In an aspect, receiving thecommand to perform the code commit may cause the API management deviceto perform a code pull (e.g., a pull request, etc.) related to thecommand. In an aspect, receiving the command to perform the code commitmay cause the API management device to send the command to animplementation device with an executable including a compiled version ofthe API and/or the API update.

At step 320, the API management device may determine whether the APIupdate violates one or more rules (e.g., one or more rules of an APIgovernance policy, etc.), such as one or more rules that must be adheredto after an update is implemented. The one or more rules may beapplicable to compilable and/or non-compilable code. The one or morerules may be based on visibility, stability, deprecation, and/or thelike. In determining whether the API update violates the one or morerules, the API management device may determine whether a version numberassociated with the API and/or API update is incremented according tothe one or more rules. The API management device can determine a currentversion of the API and/or the API update, assign a version to the APIand/or the API update, determine a version history associated with theAPI and/or the API update, and the like based on an API specificationassociated with the API and/or the API update. The API management devicecan receive the API specification from the client device. The APImanagement device can use the API specification as baseline informationto determine if changes (e.g., version changes, etc.) to the API and/orthe API update violate the one or more rules (e.g., the one or morerules of an API governance policy, etc.). The API management device candetermine changes (e.g., version changes, etc.) to an API and/or an APIupdate to ensure that the API and/or the API update, when implemented,performs as a user (e.g., developer, etc.) may expect. The APImanagement device can enable/disable changes to an API and/or an APIupdate. For example, when the API management device receives an APIand/or an API update comprising a major version update of the API, thenone or more portions of the API and/or an API update can be added,removed, or updated.

In determining whether the API update violates the one or more rules,the API management device may determine whether the API and/or the APIupdate violates a rule(s) (e.g., one or more rules of an API governancepolicy, etc.) associated with a visibility attribute of the API and/orthe API update. For example, the API management device, based on the APIspecification, can determine whether the API and/or the API update (or aportion of the API and/or the API update) is private, public, partnered,restricted, or the like. For example, the API specification may indicatea particular visibility attribute to be associated with the API and/orthe API update (or a portion of the API and/or the API update). The APImanagement device can access code associated with the API and/or the APIupdate (or a portion of the API and/or the API update) to determine if avisibility attribute within the code coincides with a the visibilityattribute indicated by the API specification. The API management devicecan be configured to prevent a visibility attribute associated with anAPI (e.g., a non-deprecated portion of the API) from transitioning from“Public” (e.g., as indicated by the API specification) to “Private”without first being deprecated according to the one or more rules (e.g.,one or more rules of an API governance policy, etc.). The API managementdevice can be configured to automatically update an API specification(e.g., API specification information stored in the database 114, etc.)according to a visibility attribute update, change, and/or modification.

In determining whether the API update violates the one or more rules,the API management device may determine whether the API and/or the APIupdate violates a rule(s) (e.g., one or more rules of an API governancepolicy, etc.) associated with stability (e.g., a stability indexassociated with an API and/or an API update). For example, the APImanagement device can determine/verify a stability index (e.g.,stability attribute, developmental rule, status, etc.) associated withan API and/or an API update. A stability index can indicate whether theAPI and/or the API update (or a portion of the API and/or the APIupdate) is in an experimental state (e.g., an API under development, anAPI operating below a performance threshold, an API the may be removedbased on versioning, etc.), a stable state (e.g., a reliable API, an APInot subject to change or revision, an API operating according to aperformance threshold, etc.), a locked state (e.g., a API that issignificantly reliable and/or not subject to a change or revision, etc.)and/or the like. The API management device, based on a stability index,can determine if the API and/or the API update violate one or more rules(e.g., one or more rules of an API governance policy, etc.) associatedwith development and implementation of the API and/or the API update canonly move in one direction, such as from an experimental state, to astable state, to a locked state.

In determining whether the API update violates the one or more rules,the API management device may determine whether the API and/or the APIupdate violate a rule(s) (e.g., one or more rules of an API governancepolicy, etc.) associated with deprecation of the API and/or the APIupdate. The API management device can determine/verify a deprecationrule associated with an API based on information received with the API(e.g., an API specification, etc.). The API management device, based ona deprecation rule, can determine portions of an API that have removed,modified, or the like in accordance to and/or in violation of the one ormore rules (e.g., one or more rules of an API governance policy, etc.),such as a determined time period. The determined time period can bebased on the visibility attribute, the stability index, or any otherfactor. For example, the API management device can determine whether aportion of an API and/or the API update has been removed, modified, orthe like, such as by an API update, by determining a date of deprecationassociated with the portion of the API and/or the API update. The APImanagement device can determine a deprecation period for the API and/orthe API update and determine whether a time period between a date of theAPI and/or the API update and the date of deprecation exceeds thedeprecation period.

Based on whether the API update violates the one or more rules (e.g.,the one or more rules of an API governance policy, etc.), the APImanagement device may either deny or allow the command. At step 330, thecommand may be denied based on a determination that the API updateviolates the one or more rules. Denying the command may comprise denyinga command to perform a code commit (e.g., a push request etc.), or anyother operation. Denying the command may prevent APIs and/or the APIupdates from being committed to an implementation device (e.g., theimplementation device 116, a code repository, a code executor, aproduction server, etc.) that does not adhere to an expected APIfunctionality and/or convention, even though the APIs and/or the APIupdates (e.g., source code) may compile without error and/or passthrough a test suite. At step 340, the command may be allowed based on adetermination that the API update does not violate the one or morerules. Allowing the command to may comprise allowing a command toperform a code commit (e.g., a push request etc.), or any otheroperation.

FIG. 4 is a flowchart of an example method 400 for application programinterface (API) management. At step 410, a command to perform an actionwith a version control system may be received. As an example, an APImanagement device (e.g., the API management device 104, version controlsystem, etc.) may receive the command from a client device (e.g., theclient device 102, a code generation device, a code management device,an API development device, etc.). The action may be associated with anAPI update. Implementing the command (e.g., implementing and/orperforming the API update) may comprise transmitting/providing thecommand to perform the action with the version control system to animplementation device (e.g., the implementation device 116, a coderepository, a code executor, a production server, etc.). Theimplementation device may carry out performance of the action or anyother operation related to the action. In an aspect, the action maycomprise a code commit to the version control system, a code pull fromthe version control system (e.g., a pull request, etc.), a deployment toa server, a combination thereof and/or the like.

At step 420, the API management device may determine whether the APIupdate violates one or more rules (e.g., one or more rules of an APIgovernance policy, etc.), such as one or more rules that must be adheredto after an update is implemented. The one or more rules may beapplicable to compilable and/or non-compilable code. The one or morerules may be based on visibility, stability, deprecation, and/or thelike. In determining whether the API update violates the one or morerules, the API management device may determine whether a version numberassociated with the API and/or API update is incremented according tothe one or more rules. The API management device can determine a currentversion of the API and/or the API update, assign a version to the APIand/or the API update, determine a version history associated with theAPI and/or the API update, and the like based on an API specificationassociated with the API and/or the API update. The API management devicecan receive the API specification from the client device. The APImanagement device can use the API specification as baseline informationto determine if changes (e.g., version changes, etc.) to the API and/orthe API update violate the one or more rules (e.g., the one or morerules of an API governance policy, etc.). The API management device candetermine changes (e.g., version changes, etc.) to an API and/or an APIupdate to ensure that the API and/or the API update, when implemented,performs as a user (e.g., developer, etc.) may expect. The APImanagement device can enable/disable changes to an API and/or an APIupdate. For example, when the API management device receives an APIand/or an API update comprising a major version update of the API, thenone or more portions of the API and/or an API update can be added,removed, or updated.

In determining whether the API update violates the one or more rules,the API management device may determine whether the API and/or the APIupdate violates a rule(s) (e.g., one or more rules of an API governancepolicy, etc.) associated with a visibility attribute of the API and/orthe API update. For example, the API management device, based on the APIspecification, can determine whether the API and/or the API update (or aportion of the API and/or the API update) is private, public, partnered,restricted, or the like. For example, the API specification may indicatea particular visibility attribute to be associated with the API and/orthe API update (or a portion of the API and/or the API update). The APImanagement device can access code associated with the API and/or the APIupdate (or a portion of the API and/or the API update) to determine if avisibility attribute within the code coincides with a the visibilityattribute indicated by the API specification. The API management devicecan be configured to prevent a visibility attribute associated with anAPI (e.g., a non-deprecated portion of the API) from transitioning from“Public” (e.g., as indicated by the API specification) to “Private”without first being deprecated according to the one or more rules (e.g.,one or more rules of an API governance policy, etc.). The API managementdevice can be configured to automatically update an API specification(e.g., API specification information stored in the database 114, etc.)according to a visibility attribute update, change, and/or modification.

In determining whether the API update violates the one or more rules,the API management device may determine whether the API and/or the APIupdate violates a rule(s) (e.g., one or more rules of an API governancepolicy, etc.) associated with stability (e.g., a stability indexassociated with an API and/or an API update). For example, the APImanagement device can determine/verify a stability index (e.g.,stability attribute, developmental rule, status, etc.) associated withan API and/or an API update. A stability index can indicate whether theAPI and/or the API update (or a portion of the API and/or the APIupdate) is in an experimental state (e.g., an API under development, anAPI operating below a performance threshold, an API the may be removedbased on versioning, etc.), a stable state (e.g., a reliable API, an APInot subject to change or revision, an API operating according to aperformance threshold, etc.), a locked state (e.g., a API that issignificantly reliable and/or not subject to a change or revision, etc.)and/or the like. The API management device, based on a stability index,can determine if the API and/or the API update violate one or more rules(e.g., one or more rules of an API governance policy, etc.) associatedwith development and implementation of the API and/or the API update canonly move in one direction, such as from an experimental state, to astable state, to a locked state.

In determining whether the API update violates the one or more rules,the API management device may determine whether the API and/or the APIupdate violate a rule(s) (e.g., one or more rules of an API governancepolicy, etc.) associated with deprecation of the API and/or the APIupdate. The API management device can determine/verify a deprecationrule associated with an API based on information received with the API(e.g., an API specification, etc.). The API management device, based ona deprecation rule, can determine portions of an API that have removed,modified, or the like in accordance to and/or in violation of the one ormore rules (e.g., one or more rules of an API governance policy, etc.),such as a determined time period. The determined time period can bebased on the visibility attribute, the stability index, or any otherfactor. For example, the API management device can determine whether aportion of an API and/or the API update has been removed, modified, orthe like, such as by an API update, by determining a date of deprecationassociated with the portion of the API and/or the API update. The APImanagement device can determine a deprecation period for the API and/orthe API update and determine whether a time period between a date of theAPI and/or the API update and the date of deprecation exceeds thedeprecation period.

Based on whether the API update violates the one or more rules, the APImanagement device may either deny or allow the action. At step 430, theaction may be denied based on a determination that the API updateviolates the one or more rules. Denying the action may comprise denyinga command to perform a code commit (e.g., a push request etc.), or anyother operation. Denying the command to implement the API and/or the APIupdate may prevent APIs and/or the API updates from being committed toan implementation device (e.g., the implementation device 116, a coderepository, a code executor, a production server, etc.) that does notadhere to an expected API functionality and/or convention, even thoughthe APIs and/or the API updates (e.g., source code) may compile withouterror and/or pass through a test suite. At step 440, the action may beallowed based on a determination that the API update does not violatethe one or more rules. Allowing the action to may comprise allowing acommand to perform a code commit (e.g., a push request etc.), or anyother operation.

In an aspect, the methods and systems can be implemented on a computer301 as illustrated in FIG. 5 and described below. By way of example, theclient device 102, the API management device 104, and the implementationdevice 116 of FIG. 1 can be a computer as illustrated in FIG. 5.Similarly, the methods and systems disclosed can utilize one or morecomputers to perform one or more functions in one or more locations.FIG. 5 is a block diagram illustrating an exemplary operatingenvironment for performing the disclosed methods. This exemplaryoperating environment is only an example of an operating environment andis not intended to suggest any limitation as to the scope of use orfunctionality of operating environment architecture. Neither should theoperating environment be interpreted as having any dependency orrequirement relating to any one or combination of components illustratedin the exemplary operating environment.

The present methods and systems can be operational with numerous othergeneral purpose or special purpose computing system environments orconfigurations. Examples of well-known computing systems, environments,and/or configurations that can be suitable for use with the systems andmethods comprise, but are not limited to, personal computers, servercomputers, laptop devices, and multiprocessor systems. Additionalexamples comprise set top boxes, programmable consumer electronics,network PCs, minicomputers, mainframe computers, distributed computingenvironments that comprise any of the above systems or devices, and thelike.

The processing of the disclosed methods and systems can be performed bysoftware components. The disclosed systems and methods can be describedin the general context of computer-executable instructions, such asprogram modules, being executed by one or more computers or otherdevices. Generally, program modules comprise computer code, routines,programs, objects, components, data structures, etc. that performparticular tasks or implement particular abstract data types. Thedisclosed methods can also be practiced in grid-based and distributedcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed computing environment, program modules can be located inboth local and remote computer storage media including memory storagedevices.

Further, one skilled in the art will appreciate that the systems andmethods disclosed herein can be implemented via a general-purposecomputing device in the form of a computer 501. The components of thecomputer 501 can comprise, but are not limited to, one or moreprocessors 503, a system memory 512, and a system bus 513 that couplesvarious system components including the one or more processors 503 tothe system memory 512. The system can utilize parallel computing.

The system bus 513 represents one or more of several possible types ofbus structures, including a memory bus or memory controller, aperipheral bus, an accelerated graphics port, or local bus using any ofa variety of bus architectures. By way of example, such architecturescan comprise an Industry Standard Architecture (ISA) bus, a MicroChannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a VideoElectronics Standards Association (VESA) local bus, an AcceleratedGraphics Port (AGP) bus, and a Peripheral Component Interconnects (PCI),a PCI-Express bus, a Personal Computer Memory Card Industry Association(PCMCIA), Universal Serial Bus (USB) and the like. The bus 513, and allbuses specified in this description can also be implemented over a wiredor wireless network connection and each of the subsystems, including theone or more processors 503, a mass storage device 504, an operatingsystem 505, API management software 506, coding data 507, a networkadapter 508, the system memory 512, an Input/Output Interface 510, adisplay adapter 509, a display device 511, and a human machine interface502, can be contained within one or more remote computing devices 514a,b,c at physically separate locations, connected through buses of thisform, in effect implementing a fully distributed system.

The computer 501 typically comprises a variety of computer readablemedia. Exemplary readable media can be any available media that isaccessible by the computer 501 and comprises, for example and not meantto be limiting, both volatile and non-volatile media, removable andnon-removable media. The system memory 512 comprises computer readablemedia in the form of volatile memory, such as random access memory(RAM), and/or non-volatile memory, such as read only memory (ROM). Thesystem memory 512 typically contains data such as the coding data 507and/or program modules such as the operating system 505 and the APImanagement software 506 that are immediately accessible to and/or arepresently operated on by the one or more processors 503.

In another aspect, the computer 501 can also comprise otherremovable/non-removable, volatile/non-volatile computer storage media.By way of example, FIG. 5 illustrates the mass storage device 504 whichcan provide non-volatile storage of computer code, computer readableinstructions, data structures, program modules, and other data for thecomputer 501. For example and not meant to be limiting, the mass storagedevice 504 can be a hard disk, a removable magnetic disk, a removableoptical disk, magnetic cassettes or other magnetic storage devices,flash memory cards, CD-ROM, digital versatile disks (DVD) or otheroptical storage, random access memories (RAM), read only memories (ROM),electrically erasable programmable read-only memory (EEPROM), and thelike.

Optionally, any number of program modules can be stored on the massstorage device 504, including by way of example, the operating system505 and the API management software 506. Each of the operating system505 and the API management software 506 (or some combination thereof)can comprise elements of the programming and the API management software506. The coding data 507 can also be stored on the mass storage device504. The coding data 507 can be stored in any of one or more databasesknown in the art. Examples of such databases comprise, DB2®, Microsoft®Access, Microsoft® SQL Server, Oracle®, MySQL, PostgreSQL, and the like.The databases can be centralized or distributed across multiple systems.

In another aspect, the user can enter commands and information into thecomputer 501 via an input device (not shown). Examples of such inputdevices comprise, but are not limited to, a keyboard, pointing device(e.g., a “mouse”), a microphone, a joystick, a scanner, tactile inputdevices such as gloves, and other body coverings, and the like These andother input devices can be connected to the one or more processors 503via the human machine interface 502 that is coupled to the system bus513, but can be connected by other interface and bus structures, such asa parallel port, game port, an IEEE 1394 Port (also known as a Firewireport), a serial port, or a universal serial bus (USB).

In yet another aspect, the display device 511 can also be connected tothe system bus 513 via an interface, such as the display adapter 509. Itis contemplated that the computer 501 can have more than one displayadapter 309 and the computer 501 can have more than one display device511. For example, the display device 511 can be a monitor, an LCD(Liquid Crystal Display), or a projector. In addition to the displaydevice 511, other output peripheral devices can comprise components suchas speakers (not shown) and a printer (not shown) which can be connectedto the computer 501 via the Input/Output Interface 510. Any step and/orresult of the methods can be output in any form to an output device.Such output can be any form of visual representation, including, but notlimited to, textual, graphical, animation, audio, tactile, and the like.The display device 511 and computer 501 can be part of one device, orseparate devices.

The computer 501 can operate in a networked environment using logicalconnections to one or more remote computing devices 514 a,b,c. By way ofexample, a remote computing device can be a personal computer, portablecomputer, smartphone, a server, a router, a network computer, a peerdevice or other common network node, and so on. Logical connectionsbetween the computer 501 and a remote computing device 514 a,b,c can bemade via a network 515, such as a local area network (LAN) and/or ageneral wide area network (WAN). Such network connections can be throughthe network adapter 508. The network adapter 508 can be implemented inboth wired and wireless environments. Such networking environments areconventional and commonplace in dwellings, offices, enterprise-widecomputer networks, intranets, and the Internet.

For purposes of illustration, application programs and other executableprogram components such as the operating system 505 are illustratedherein as discrete blocks, although it is recognized that such programsand components reside at various times in different storage componentsof the computing device 501, and are executed by the one or moreprocessors 503 of the computer. An implementation of the API managementsoftware 506 can be stored on or transmitted across some form ofcomputer readable media. Any of the disclosed methods can be performedby computer readable instructions embodied on computer readable media.Computer readable media can be any available media that can be accessedby a computer. By way of example and not meant to be limiting, computerreadable media can comprise “computer storage media” and “communicationsmedia.” “Computer storage media” comprise volatile and non-volatile,removable and non-removable media implemented in any methods ortechnology for storage of information such as computer readableinstructions, data structures, program modules, or other data. Exemplarycomputer storage media comprises, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by a computer.

The following examples are put forth so as to provide those of ordinaryskill in the art with a complete disclosure and description of how thecompounds, compositions, articles, devices and/or methods claimed hereinare made and evaluated, and are intended to be purely exemplary and arenot intended to limit the scope of the methods and systems. Efforts havebeen made to ensure accuracy with respect to numbers (e.g., amounts,temperature, etc.), but some errors and deviations should be accountedfor. Unless indicated otherwise, parts are parts by weight, temperatureis in ° C. or is at ambient temperature, and pressure is at or nearatmospheric.

The methods and systems can employ Artificial Intelligence techniquessuch as machine learning and iterative learning. Examples of suchtechniques include, but are not limited to, expert systems, case basedreasoning, Bayesian networks, behavior based AI, neural networks, fuzzysystems, evolutionary computation (e.g. genetic algorithms), swarmintelligence (e.g. ant algorithms), and hybrid intelligent systems (e.g.Expert inference rules generated through a neural network or productionrules from statistical learning).

While the methods and systems have been described in connection withpreferred embodiments and specific examples, it is not intended that thescope be limited to the particular embodiments set forth, as theembodiments herein are intended in all respects to be illustrativerather than restrictive.

Unless otherwise expressly stated, it is in no way intended that anymethod set forth herein be construed as requiring that its steps beperformed in a specific order. Accordingly, where a method claim doesnot actually recite an order to be followed by its steps or it is nototherwise specifically stated in the claims or descriptions that thesteps are to be limited to a specific order, it is in no way intendedthat an order be inferred, in any respect. This holds for any possiblenon-express basis for interpretation, including: matters of logic withrespect to arrangement of steps or operational flow; plain meaningderived from grammatical organization or punctuation; the number or typeof embodiments described in the specification.

Throughout this application, various publications are referenced. Thedisclosures of these publications in their entireties are herebyincorporated by reference into this application in order to more fullydescribe the state of the art to which the methods and systems pertain.

It will be apparent to those skilled in the art that variousmodifications and variations can be made without departing from thescope or spirit. Other embodiments will be apparent to those skilled inthe art from consideration of the specification and practice disclosedherein. It is intended that the specification and examples be consideredas exemplary only, with a true scope and spirit being indicated by thefollowing claims.

1. A method comprising: receiving a request for an implementation deviceto perform an update to an Application Program Interface (API);determining, based on the request and an API stability index, a currentstate of the API; and causing, based on the current state of the API,performance of the update by the implementation device to be blocked. 2.The method of claim 1, wherein the current state of the API comprises anexperimental state, and wherein causing performance of the update by theimplementation device to be blocked comprises causing the implementationdevice to deny a code commit comprising the update.
 3. The method ofclaim 2, further comprising determining that the current state of theAPI comprises the experimental state based on at least one of:determining, based on at least one attribute in the API stability indexassociated with the API, that the API is under development; determining,based on the at least one attribute in the API stability index, that theAPI is operating below a performance threshold; or determining, based onthe at least one attribute in the API stability index, that the API isto be removed, disabled, or deprecated.
 4. The method of claim 1,wherein the current state of the API comprises a stable state, andwherein causing performance of the update by the implementation deviceto be blocked comprises causing the implementation device to deny a codecommit comprising the update.
 5. The method of claim 4, furthercomprising determining that the current state of the API comprises thestable state based on at least one of: determining, based on at leastone attribute in the API stability index associated with the API, areliability of the API indicative of the stable state; determining,based on the at least one attribute in the API stability index, that theAPI is not subject to an API revision; or determining, based on the atleast one attribute in the API stability index, that the API isoperating at or above a performance threshold.
 6. The method of claim 1,wherein the current state of the API comprises a locked state, andwherein causing performance of the update by the implementation deviceto be blocked comprises causing the implementation device to deny a codecommit comprising the update.
 7. The method of claim 6, furthercomprising determining that the current state of the API comprises thelocked state based on at least one of: determining, based on at leastone attribute in the API stability index associated with the API, areliability of the API indicative of the locked state; or determining,based on the at least one attribute in the API stability index, that theAPI is not subject to an API revision.
 8. An apparatus comprising: atleast one processor; and memory storing processor-executableinstructions that, when executed by the at least one processor, causethe apparatus to: receive a request for an implementation device toperform an update to an Application Program Interface (API); determine,based on the request and an API stability index, a current state of theAPI; and cause, based on the current state of the API, performance ofthe update by the implementation device to be blocked.
 9. The apparatusof claim 8, wherein the current state of the API comprises anexperimental state, and wherein the processor-executable instructionsthat cause the apparatus to cause performance of the update by theimplementation device to be blocked further cause the apparatus to causethe implementation device to deny a code commit comprising the update.10. The apparatus of claim 9, wherein the processor-executableinstructions that cause the apparatus to determine that the currentstate of the API comprises the experimental state further cause theapparatus to at least one of: determining, based on at least oneattribute in the API stability index associated with the API, that theAPI is under development; determining, based on the at least oneattribute in the API stability index, that the API is operating below aperformance threshold; or determining, based on the at least oneattribute in the API stability index, that the API is to be removed,disabled, or deprecated.
 11. The apparatus of claim 8, wherein thecurrent state of the API comprises a stable state, and wherein theprocessor-executable instructions that cause the apparatus to causeperformance of the update by the implementation device to be blockedfurther cause the apparatus to cause the implementation device to deny acode commit comprising the update.
 12. The apparatus of claim 11,wherein the processor-executable instructions that cause the apparatusto determine that the current state of the API comprises the stablestate further cause the apparatus to at least one of: determining, basedon at least one attribute in the API stability index associated with theAPI, a reliability of the API indicative of the stable state;determining, based on the at least one attribute in the API stabilityindex, that the API is not subject to an API revision; or determining,based on the at least one attribute in the API stability index, that theAPI is operating at or above a performance threshold.
 13. The apparatusof claim 8, wherein the current state of the API comprises a lockedstate, and wherein the processor-executable instructions that cause theapparatus to cause performance of the update by the implementationdevice to be blocked further cause the apparatus to cause theimplementation device to deny a code commit comprising the update. 14.The apparatus of claim 13, wherein the processor-executable instructionsthat cause the apparatus to determine that the current state of the APIcomprises the locked state further cause the apparatus to at least oneof: determining, based on at least one attribute in the API stabilityindex associated with the API, a reliability of the API indicative ofthe locked state; or determining, based on the at least one attribute inthe API stability index, that the API is not subject to an API revision.15. A system comprising: an Application Program Interface (API); aclient device; an implementation device; and a management device,wherein the management device is configured to: receive, from the clientdevice, a request for the implementation device to perform an update tothe API; determine, based on the request and an API stability index, acurrent state of the API; and cause, based on the current state of theAPI, performance of the update by the implementation device to beblocked.
 16. The system of claim 15, wherein the current state of theAPI comprises an experimental state, and wherein the management deviceis further configured to cause the implementation device to deny a codecommit comprising the update, wherein the code commit is received by theimplementation device from the client device.
 17. The system of claim16, wherein the management device is configured to determine that thecurrent state of the API comprises the experimental state by:determining, based on at least one attribute in the API stability indexassociated with the API, that the API is under development; determining,based on the at least one attribute in the API stability index, that theAPI is operating below a performance threshold; or determining, based onthe at least one attribute in the API stability index, that the API isto be removed, disabled, or deprecated.
 18. The system of claim 15,wherein the current state of the API comprises a stable state, andwherein the management device is further configured to cause theimplementation device to deny a code commit comprising the update,wherein the code commit is received by the implementation device fromthe client device.
 19. The system of claim 18, wherein the managementdevice is configured to determine that the current state of the APIcomprises the stable state by: determining, based on at least oneattribute in the API stability index associated with the API, areliability of the API indicative of the stable state; determining,based on the at least one attribute in the API stability index, that theAPI is not subject to an API revision; or determining, based on the atleast one attribute in the API stability index, that the API isoperating at or above a performance threshold.
 20. The system of claim15, wherein the current state of the API comprises a locked state, andwherein the management device is further configured to cause theimplementation device to deny a code commit comprising the update,wherein the code commit is received by the implementation device fromthe client device.